I don't think AUTHENTICATED is the right event here. An AUTHENTICATED event is audit logged every time a request is sent with valid credentials.

To monitor changes to the security index, I think you would use the compliance: section of the audit log config. Specifically, the write_watched_indices: [] here.

The security index is .opendistro_security. If you add it into this list, you should be able to track changes to internalusers, roles, roles_mappings, etc.

Thanks, Craig. I've just tried to put AUTHENTICATED event back to the list of the disabled categories and added the .opendistro_security index to the write_watched_indices list. And it didn't seem to be enough to get the details like the created or deleted user account name. To get that details, I had to disable write_metadata_only and enable write_log_diffs options as well.
Please, confirm this is the right way to go and I'll update my PR

Yes, that's correct. Does the section below look correct to you? Is there anything else that needs to be added?

_meta:
  type: "audit"
  config_version: 2

config:
  # enable/disable audit logging
  enabled: true

  ...


  compliance:
    # enable/disable compliance
    enabled: true

    # Log updates to internal security changes
    internal_config: true

    # Log only metadata of the document for write events
    write_metadata_only: false

    # Log only diffs for document updates
    write_log_diffs: true

    # List of indices to watch for write events. Wildcard patterns are supported
    # write_watched_indices: ["twitter", "logs-*"]
    write_watched_indices: [".opendistro_security"]

yes, looks just fine, thank you! i'd just add a comment regarding the specified .opendistro_security index to make people aware why it's added by default

would you like me to update my PR? or i can simply delete it if you're going to update the docs by yourself

Yes please update this PR. Thank you @jazzl0ver ! This will be a great addition to the documentation.

@cwperks updated

wdyt including the entire section from the above comment?

In general, the audit logs documentation on the documentation website looks like it could be updated to describe all potential settings in the audit.yml file in a table and the compliance portion of the audit log needs to be expanded upon.

For this PR, I think including the blurb from above would be an improvement on the existing docs.

done